NetNews Offline 2/NetNews Offline Volume 2.iso/news/comp/sys/amiga/hardware-part1/2780

Internet Message Format | 1996-08-05 | 10.8 KB

Path: sdd.hp.com!inn
From: Jeff Grimmett <[e-mail]>
Newsgroups: comp.sys.amiga.hardware
Subject: Re: A3000 SCSI
Date: 28 Jan 1996 18:03:49 GMT
Organization: Hewlett-Packard Company
Message-ID: <4egdq5$[e-mail]>
References: <4crkgh$[e-mail]> <4djffa$[e-mail]> <4dlre0$[e-mail]> <4e0amr$[e-mail]> <4e0jru$[e-mail]> <4edjsc$[e-mail]>
NNTP-Posting-Host: hpsdv330.sdd.hp.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailer: Mozilla 1.2N (Windows; I; 16bit)

[e-mail] (Warren Block) wrote:

>: >Unless you have two controllers, you only have one SCSI bus, and the SCSI
>: >spec is very clear on termination and the other rules (a couple of which
>: >C= broke on the A3000).
>
>: So theory and reality collide, and guess what?  Reality wins again.
>
>No, C= chose to do a couple of things wrong, and the users are the ones
>who had to put up with it.  As usual.  To be fair, there may not have
>been any conscious choice involved; things like the DB25 connector may
>just have been "the way you do it" at that time.

First of all, you're missing my point throughout this article.  That
being: design specs are one thing, the way the hardware WORKS is
another thing completely.  You can build a thing completely from specs,
BY THE BOOK, and it can STILL turn around and suprise you, at which point
you have the choice of dealing with the behavior and understanding it, or
changing it until it meets spec.

CBM, when they found of the noncompliancies of thier design, had a few
options open.  They could to the noble thing: redesign the SCSI system,
recall all previous rev boards, and replace them.  Even the auto industry
tries to avoid THIS. They could change the design and replace just the
motherboards that came back for service, and use the new design in later
revs.  I think this partially happened.  OR, they could issue a bulletin
to techs out there notifying them of the inconsistency and give pointers
on how to live with it.  This is what they did for the rev 9.1
motherboard, at least.

THAT is the reality we have to deal with.  The 3000 does NOT comply 100%
with SCSI specs.  It comes close.  DAMNED close.  It is, for my money,
one of the most compliant controllers for the Amiga market, with the 2091
edging it out.  This does nothing to deny the reality that there are one
or two exceptions to every rule.

As for the DB25 connector: I think they made a good choice with it, to
tell the truth, in the same way that they made a good choice by using the
standard Centronics port -- that's what was out there, that's what was
supported, and it's the most affordable for both them AND the customer.
Sure, 50-pins connectors are better from MANY viewpoints, but the things
are EXPENSIVE compared to even top quality DB25 to 50-pin cables. Ever
price one of the high-density 50 pin cables?  I can get a DB25 type for
$15, very good quality build.  The same company also sells a high-density
cable.  For SIXTY fraggin' dollars.

>: Whether the SCSI specs agree or not, this is what IS for the A3000.
>
>Oh no, not again.  Please don't think that I'm running down the A3000,
>because I'm not.

Not at all. I just don't think you are recognizing the difference between
a specification and the resulting design that comes from one.

>  I'm trying to convince people that SCSI works better if
>you follow the rules.

Generally, it does.

>  A SCSI bus set up as per the C= documents you
>describe may work, but it will more likely work, and work reliably, if
>you know the rules and follow them.

For a theoretical controller, what you are saying makes PERFECT sense.

For a non-theoretical piece of machinery, it MAY make sense.

For a non-theoretical A3000 with rev 9.1 main PCA, it only makes sense if
you pay heed to the exceptions that apply to THAT MACHINE ONLY.

>: My 3000 has operated for 5 years now with no problems on the SCSI bus
>: because I am playing by the rules of the hardware at my disposal, rather
>: than the specs that this hardware doesn't agree with.  I've been through
>: more SCSI reconfigurations on my 3000 than my car has had tune-ups.
>
>I'm not certain what this shows, but if we're talking examples:

It SHOWS that by observing the rules of SPECIFIC HARDWARE as defined by
the manufacturer of that hardware, in addenum to the technical manual,
that the machine works great.  It says NOTHING, zip, nil, nada, about any
other machine on the planet or SCSI in general.


>A friend of mine had an old single-speed CD-ROM drive which he wanted to
>attach to a 2091 (very similar controller circuitry to what is in the

The 2091 does not share the same design flaws as the 3000.  It has some
of its own, mostly fixable through firmware, but not the same ones as
the 3000.  In most cases you can generally speak of the 3000 and 2091 in
the same breath, but NOT with regard to a technical bulletin that
SPECIFICALLY was issued for ONE model of equipment and ONE specific
motherboard revision.

It's like saying that a technical bulletin issued by Ford applies to
Audis.

>What I'm trying to say is that as more SCSI devices are added, and as the
>bus length grows, accurate termination becomes more and more critical.

I will not disagree with this at all.  I will only say that if there are
exceptions for the equipment you use, you should observe those in
precedence to other guidelines.

>: It's an abberation, which I think I implied, granted.  But since we have
>: to play by ITS rules....

>The aberration was on the part of the documentation you described; please
>don't force the A3000 to fit into that mold.

I'm starting to get the idea that anything that doesn't agree 100% with
the original design spec holds no credibility with you.  I do not have
any idea why you can't accept that technical bulletins are a method to
correct mistakes made in design specs, and I can't understand why you
can't accept that design specs are sometimes flawed.

By your reasoning, every car build in Detroit is by definition perfect,
and the dozens of later technical bulletins released by the car's
manufacturer and, by this argument, incorrect and should be ignored.

I've gone as far on this argument as I intend to.  It's wearing thin. I
will say this one more time, and leave it;

Like it or not, the A3000 was released with many flaws.

Like it or not, these flaws were in the original design.

Like it or not, the WD chip, Ramsey, and Buster all had flaws in them.

Like it or not, there were other flaws on the motherboard itself.

Like it or not, these exceptions were caught and documented.  They were
documented in the form of technical bulletins to authorized technicians
and agents of CBM.

Like it or not, these exceptions must be dealt with on thier own terms on
a case by case basis.  You replace the WD, Ramsey, and Buster chips with
newer ones, in accordance with the technical bulletins.  You reverse the
polarity of the improperly inserted diode.  You cut a trace, solder a
bridge, or replace a component as indicated.

The Rev 9.1 SCSI termination technical bulletin could have been issued
for any number of reasons -- a fundamental flaw in the SCSI bus drivers
that was later corrected, incorrect documentation in the technical
manual... who's to say?  However, if one accepts as a given that other
technical bulletins released for openly acknowledged problems WERE
correct, one would have a hard time justifying NOT accepting others.

I do not understand why you cannot accept that exceptions can exist and
must be dealt with on thier own terms.  Until you DO accept that, I don't
see this series of posts going anywhere except in a circle.  I for one am
not fond of beating expired equines.

>: >  As for C=, well, they went out of business due to
>: >stupidity...
>
>: Am I to infer, then, that you have a low opinion of the OS because of the
>: actions of Medhi Ali?  What have the poor business decisions of one man
>: to do with the design decisions of the A3000? Phbt.

>I was trying to infer that C= may have (and indeed, did) make mistakes in
>some things, and that's how I would classify these documents you
>describe.

.. so, the ones that described the acknowledged diode reversal must
therefore fall into the same category?  It is almost certain that the
same persons were responsible for the issue of both technical bulletins.


>  Now that I think about it, it may have been a way of avoiding
>blame for not socketting the terminators.

My terminators are socketed.  Many people have said thiers are, too, in
this newsgroup.  Care to revise your statement?

>  The user may take a dim view
>of a manual telling them they have to unsolder a SIP when the SCSI bus
>has both internal and external devices.

This makes no sense IN THE CONTEXT OF THE TIME IN QUESTION. At that time,
all 3000's were sold with Gold Service contracts.  Problems like this
were openly acknowledge and repaired free of cost to the user. This is
how I learned of this technical bulletin, chatting with the tech as he
replaced my motherboard under that contract.  I have not implied at any
time that this technical bulletin applied to later revs of the
motherboard that might have been released after the termination of the
Gold Service program.


>: >Some A3000s will work fine with non-spec SCSI setups.
>
>: The A3000 is a non-spec system from the very start.
>
>Huh?  In what way is the A3000 SCSI non-standard, other than a minor flaw
>in the way it is documented?  Please be specific.

Well, since you won't accept the notion that at least early A3000
motherboards had a problem with SCSI bus impendence, and thus requiring
non-standard termination configurations, I sense a trap.  Fortunately, I
don't need to dig too much further.  While it claims SCSI-II command
compliance, you can not enable and disable synchronous transfers on a
drive by drive basis.  You can only enable and disable synchronous
transfers globally, for all drives or none of them.  This was openly
acknowledge in both technical bulletin AND in developer documentation.

I consider that non-spec.  Don't know if you do or not.


>: >  That doesn't mean
>: >that the settings are proper,
>
>: The settings are proper for that machine, only, and do not necessarilly
>: apply to any other model, including the T.
>
>Consider that the A3000 uses a standard SCSI controller chip attached to a
>standard SCSI bus, to be used for attaching standard SCSI peripherals.
>Note that the SCSI controller chip is what speaks to the SCSI bus, not
>some custom A3000 circuitry.

OK, throw a WD chip, some SCSI driver chips, some resistors, and whatever
else you think would be appropriate into a cardboard box, close the lid,
and shake vigorously.  Have you now ended up with a standard SCSI
controller?  Let me know if this works, I always wanted to get rich.

I trust that my point is made.